I think this setup assumes a bit too much about where the worker code file is.
I think a middle ground would be to immitate the csp idea in terms of setup and have that support both esm and cjs.
It means the user would need to specify where the worker code is, instead of the current assumption that it is next to the main thread code. I think it will also make sure that it will be supported with all kinds of bundlers.
This is similar to RTL plugin and CSP and I think it's a smaller change, and had better chances to work correctly.

@HarelM , i've split it out so that the worker url is set explicitly

https://github.com/maplibre/maplibre-gl-js/pull/6254/files#diff-538d7808b52996feefd0ff81d905bfb0dbcc1351484e2d255261769ebdb1f362R43-R48

I've also added build tests to make sure the esm build is actually esm (they don't go deep though, because i.e. murmurhash.js does have module.export still, but the outermost layer is esm)

This looks great! Thanks!
I've added a few minor comments.

I would recommend also to use npm run pack and check the output in another project with bundling etc.
The fact that this now has esm might be the default for some bundlers and might cause them to pack only the esm part of the main thread instead of the cjs and cause app to stop working, so this needs to be tested as well.
You can use npx-maplibre-gl as an angular project to test and maybe Maputnic as react one.

I've tried npm pack, and loading it into maputnik node_modules, which appear to work fine. I believe it's still just using the .js version, rather than the new .mjs

ngx-maplibre-gl appear to pick up the esm module in the showcase, so it'll only work if the showcase/main.ts file has the setWorkerUrl added - otherwise the map will just be the light blue background without data.

import { bootstrapApplication } from '@angular/platform-browser';
import { appConfig } from './app/app.config';
import { AppComponent } from './app/app.component';
import * as maplibregl from 'maplibre-gl';

// Set the worker URL for MapLibre GL when using ESM version
maplibregl.setWorkerUrl('/maplibre-gl/maplibre-gl-worker.mjs');

bootstrapApplication(AppComponent, appConfig).catch((err) =>
  console.error(err)
);

Either we can use the auto-worker url like there was logic for previously, or this might have to come as a breaking change if the default will be an explicit setting of the worker url.

Or both, having the auto-url logic now, and requiring explicit url from next major.

I don't think the auto-worker url will work for angular (webpack) unfortunately.
So I'm not sure there's a way around this a breaking change, which is ok as we haven't released a breaking change version this year, and we might need to consider this.
But if we are doing a breaking change version we need to collect breaking changes requirements like we did for v5.

I think going ESM-only in v6 is the right call here.

I would expect to see more documentation on how to use this new ESM build, one of the places is probably here:
https://github.com/maplibre/maplibre-gl-js/blob/main/docs/index.md

But I think there might be a need for more descriptive information, maybe some info on packagers such as webpack and rollup...

• Relevant tracking issue: v6 breaking changes features #6427

@louwers told me so!

This is on the roadmap to version 6, which is the next breaking change version, it's just not clear when we would create a breaking change version...

I'm experimenting to use the ESM modules with Vite/React Router v7. If you need any feedback, just contact me.

Works so far like this:

import {  Map, setWorkerURL } from "maplibre-gl";
import webWorkerURL from "maplibre-gl/dist/maplibre-gl-worker.mjs?url";
setWorkerUrl(webWorkerURL);
const map = new Map(...);

Vite loads the CJS module when using SSR (as far as I understood because NodeJS resolution is used on the server side per default). To prevent that, one can set it up like this in vite.config.ts to use Vites resolution (which uses ESM per default):

export default defineConfig({
  ...,
  ssr: {
    noExternal: ['maplibre-gl'],
  },
});

Not sure if this is the best solution. "noExternal" might decrease module resolution performance on the server side.

@chrneumann The ?url search parameter is a non-standard Vite feature. This issue is about distributing an ESM build that can be used directly by browsers without a bundler.

But it will also be used with bundlers? And this needs documentation (#6254 (comment))? Anyways, maybe it's helpful for someone who wants to use the ESM build with Vite as I do :)